Computing systems that provide continuous services to a base of users or remote clients have struggled with the task associated with maintaining and operating multiple versions of a set of applications or components as upgrades to existing systems are installed. In the past, installations would need to be made upon a second server, and at some point in time, all new requests for services are routed to the new servers until all pending actions are completed on the server running the older version of the applications. A separate server is typically needed because a component's class ID is set within the binary version of the component at compile time and because the class Ids must be unique within a computing system.
Additionally, some computing systems need to provide functionality to various users depending upon the rights the user has been granted by a directory system. While this additional functionality may be limited to a subset of all users, the majority of the functionality provided by an application is common to most, if not all, users. Current component-based programming systems implement these different sets of functionality using different components. However, developers who wish to simply alter one component to provide the additional functionality to a small subset of users are required to recompile a significant amount of code in order to assign a new class ID to the newly generated component that implements the new functionality.
This has disadvantages. One such disadvantage is that it is inconvenient and expensive in terms of the number of servers required and in the administration of those servers. Another such disadvantage is that it is difficult to update shared components. Another disadvantage is that a test version of an application cannot be executed on the same server as a production version of an application. Therefore improvement are desirable.